In an operation system, a true hardware driver program always executes the I/O access against a certain specified hardware device and provides the application with the access interface of this specified device. However, users of the driver program, in most cases, do not care which device is being utilized. They only care whether a usable device of this type exists in the system. For example, a user such as the application program for a printer only cares whether there is a usable printer, but does not care whether the printer is a parallel one, a serial one, or network one, not to mention the printer type or trademark. In view of this, it is not reasonable for an application program utilizing a printer to specify directly the printer driver program to be used.
To solve this problem, in traditional methods the operation system divides the driver program into layers. Referring to FIG. 1, a printer driver program usually is divided into three layers, i.e. hardware I/O layer 3, print driver layer 2 and application interface layer 1. In application interface layer 1, the operation system realizes a pseudo-print driver program with the aim to provide a standard printer interface for upper layer application programs, so the application programs may utilize it without worrying about the particular printer type. The lower layer print driver program registers itself to the pseudo-driver program of a fictitious printer in installation, and the fictitious printer driver would transfer the print request of upper layer application to the particular print driver program to execute corresponding print order.
This property, which obtains various function characteristics according to the various entity object (driver program) cited by interface through an abstract interface (application interface layer 1), is referred to as polymorphism in the component-oriented (or object-oriented) technology.
The problem of isolation between an application program and a particular hardware could be resolved satisfactorily by the polymorphism characteristic. However, owing to the fact that there is no true component object model (COM) in the core of the traditional operation system to support this characteristic, there are the following two problems in this model, i.e. 1. there is no common utility and a pseudo-driver program of upper layer application-oriented is required for every kind of device; and 2. an interface layer transfer brings about an extra efficiency overhead, and sometimes unnecessary data copy.
In the COM, all the components use the class identification (CLSID) as a unique identifier of driver component class, and each CLSID corresponds to a component realization.
It is considered by COM specification that the binary polymorphism is realized if an abstract interface can be obtained. However, this does not occur in practice. When a component customer terminal utilizes a component, it needs still to specify the CLSID of the component server to create a component object, and specifying the CLSID means specifying the component realization.
Take the above printer model as an example. Suppose that the print driver programs are made up of components and all of the programs have a “common printer interface.” If it is required that the application program specifies the CLSID at the time of driver object creation, the kind of print driver program is specified, and thus the device or driver is not transparent to the application program.
So abstracting the interface out merely realizes a polymorphism in invoking the component method, but the polymorphism of component creation is not realized. The utilization of a component unavoidably requires three steps: creating, invoking and withering away. Therefore, the polymorphism in component application may be realized only if realizing the polymorphism of component creation.